The HTTP protocol may be considered part of the infrastructure in current information technology. Many applications may use this protocol for transferring many types of content (e.g. text, photos, audio objects, video objects, etc.) from servers to clients (e.g. browsers). As a result of its popularity, many methods were presented over the years for improving HTTP performance. These methods may be aimed at improving user experience and communication infrastructure usage efficiency.
One method for improving HTTP usage is to use caching, since in many cases the same content may be requested by many users (e.g. news pages, popular video objects, etc.). Upon first request, the required objects may be retrieved from a content server and stored in a cache (in addition to being forwarded to the requesting user). Thereafter, subsequent requests for the same objects may be served from the cache, i.e., the requested objects may be retrieved from the cache rather than from the content server. Use of the cache may reduce a response time for content retrieval and less bandwidth (or capacity) may be used between the requesting client and the content server.
In one refinement of said caching methods, multicasting may be used for increasing overall efficiency. Instead of, or in addition to, placing a single cache at a network center, a cache may be placed near each user. In addition, a server at a network center may be used for determining content of interest. Once content of interest is identified (either upon first request or even before it is requested for the first time), the server at the network center may retrieve this content from the content server and then send it using a multicast protocol to multiple caches of multiple users. Then, when a user requests this content, it may be retrieved from a local cache, i.e. with (almost) no latency and consuming minimal bandwidth of the communication infrastructure.
References to some of these caching methods may be found in U.S. Pat. No. 6,947,440, entitled “System and Method for Internet Page Acceleration Including Multicast Transmissions” to Chatterjee et al, the contents of which are incorporated by reference.
However, when trying to apply these caching solutions to a communication system, such as a satellite communication system, one skilled in the art may encounter several problems.
Satellite communication may be a preferred method for quickly deploying connectivity to a plurality of geographically dispersed sites. Thus, communication between users (clients) and servers may be carried over a satellite link, which may be considered as a resources-limited medium that may have undesired effects on data exchange and on user experience. For example, a satellite link may be shared between one or more users and may have limited capacity (bandwidth), hence capacity over the medium for any given user may be limited and its availability may change dynamically (for example, either due to variances in load and/or due to changes in overall capacity that may result from changes in link conditions, e.g. due to temporary rain fade in the link). In addition, a satellite link may introduce inherent latency in the excess of hundreds of milliseconds per direction, hence affecting user experience. Furthermore, a satellite link may be considered a non-reliable medium. In order to ensure integrity of the data being exchanged, reliability may need to be built into the data exchange protocol. Nevertheless, a satellite link may also have an advantage in such systems due to its ability to efficiently convey the same data to multiple users through multicast transmissions (i.e. data transmitted over the medium may be received by multiple users who choose to receive it).
In order to minimize response latency (i.e. improve user experience) as well as minimize traffic over the satellite between a client and a content server, a cache may be located as close as possible to the client requesting the content. In addition, in order for caching to be effective, the cache may need to be large enough, so that the hit ratio (i.e. the number of attempts for which the requested object may be stored in the cache compared to the total number of attempts to locate objects in the cache) may be sufficient for sustaining a quality user experience. For example, user experience may be poor if only, e.g., 50% of the objects can be found in a cache, but it may be quite good if, e.g., 90% of the objects may be found in the cache.
In case of a satellite communication system composed of a hub and a plurality of remote terminals, an approach as described above towards caching may require implementation of a cache at the remote terminal, e.g. by adding memory to the terminal's modem (or indoor unit (IDU)) and configuring the terminal to use it for caching information objects. However, increasing the amount of memory in a terminal may also increase the cost of the terminal. As the amount of memory available in a terminal's modem may be preconfigured and determined during the terminal's production (i.e. it may not be possible to add more memory to the terminal once the terminal is deployed), increasing the amount of memory per terminal during its manufacturing may result in higher terminal cost regardless of whether the excess memory is actually needed and/or used by the end user, or not.
Another method known in the art for increasing caching efficiency may be the use of multicast transmissions for distributing content of interest. It may be highly probable that certain information objects (e.g. news content, shared video clips, etc.) may interest many people hence these objects may be requested by more than one client. By multicasting such objects (either by unsolicited pushing of this content and/or following a first request for it) to a plurality of clients and by the clients storing these objects in local caches, the number of requests transmitted from these clients to content servers and the number of times that said objects may have to be transmitted to clients may be substantially reduced (i.e. as many of the requests may be fulfilled from the clients' local caches).
However, in case of a satellite communication system composed of a hub and a plurality of remote terminals, the population of terminals may not be homogenous, i.e. some of the terminals may include sufficient memory and processing power to support caching of many objects received though multicast transmission, while other terminals may have lower performance, i.e. they may not support caching and/or have lower processing power. Using state of the art multicast techniques as described above may overwhelm the lower performance terminals, which may become very busy in filtering a lot of information they have nothing to do with instead of processing traffic of interest.
Furthermore, current state of the art multicasting techniques were mostly presented prior to the introduction of Adaptive Coding and Modulation (ACM) techniques for satellite communication systems (e.g. the introduction of DVB-S2 (ETSI EN 302 307)). One purpose of ACM techniques may be to optimize channel efficiency by altering transmission characteristics (e.g. modulation and error correction coding) in accordance with capability of a receiver at a terminal to receive the transmission. However, when transmitting information in multicast, the transmission is destined to a group of terminals, hence determining which transmission characteristics to use may be quite difficult. Selecting the most robust transmission characteristics in order to maximize the probability of reception by all the potential receivers may be an inefficient solution, as it may significantly reduce the system throughput (i.e. since the most robust transmission characteristics may require the least reception capabilities but also allow transmission of the fewest information bits per each bandwidth unit).
Yet another problem with caching may be the response time when objects of interest are not stored in a cache. A method known in the art for reducing the total time it may take a client to retrieve such objects in such a scenario may be known as pre-fetching. For example, a client located at a remote terminal of a satellite communication system may issue a request for a web-page. Assuming the request might not be fulfilled from a local cache, the request may be forwarded over the satellite and via a hub of said system to a content server. The content server may reply to the request with a base object of the requested page, wherein the base object may include links to subsequent objects that may be embedded in the page (e.g. pictures, graphic elements, controls, etc.). If pre-fetching may be used in said satellite communication system, the hub may include an entity which may analyze the base object received from the content server and issue requests for the linked objects, even though the client has not yet requested these additional objects (i.e. since the client requested the page, it is highly probable that it may also request the other objects embedded in the page). When the additional objects are received from the content server, they may be transmitted to the remote terminal over the satellite.
However, even if a remote terminal has a cache, it may still send a request for the base object of the web-page, for example in order to refresh the page or if the base-object is not cacheable. In such cases, when the base-object is received at the terminal, the terminal may determine that at least some of the embedded objects may be stored in its cache and it may use the stored copies instead of fetching them over the satellite (i.e. thus reducing traffic over the satellite and provide better experience for a user). Nevertheless, said hub entity may still analyze the base page, pre-fetch all the linked objects, including those already stored in the terminal's cache, and transmit them over the satellite hence wasting valuable satellite link capacity.
Thus, when trying to apply caching solutions to a satellite communication system, several challenges may have to be met. As the medium may be quite expensive to lease from a satellite owner, one challenge may be to minimize the bandwidth required over the medium in both directions (i.e. from a remote terminal to a central site (inbound) as well as from the central site to the remote terminal (outbound)). Another challenge may be to mitigate the effects of the link latency and to minimize the interval between request and response (i.e. to improve user experience). However, since in many cases these first two challenges may be contradicting (i.e. improving user experience often requires more capacity over the satellite link), a third challenge may be to balance between the first two challenges. Yet a forth challenge may be related to service levels (sometimes referred to as service level agreement (SLA)), which a system operator may provide to users (e.g. data rates at which data is exchanged over the system). User SLA may have to be met (i.e. measured and enforced) at the user network interface (UNI, e.g. a LAN interface connecting a terminal and a user PC) regardless of any traffic optimizations on one hand (from which the system operator may benefit), or any deterioration in link conditions on the other hand, which may require additional bandwidth for meeting the SLA.